In communication networks data can be sent via transmission links from sending entities to receiving entities and for many situations it is required or at least advantageous that the sending rate of the sent data and the transmission capability of the transmission link match.
FIG. 1 is used to explain an implementation for matching the transmission capability and the sending rate for a streaming application in a mobile communication system like the UMTS system. For streaming applications, a streaming server acting as sending entity sends a stream of data packets via a transmission link (TL) to the user equipment (UE) and finally to the streaming client acting as receiving entity in this example. The transmission link (TL) comprises a link from the streaming server via a backbone network to a core network of a mobile communication network. The transmission link (TL) is further extended from the core network to the radio network which is illustrated by the RNC and to the UE. Streamed data received at the UE is passed to the streaming client, where it can be further processed, e.g. for a multi-media presentation on the UE. A part of the transmission link (TL) is build by a streaming bearer (SB), which is, according to this example, realized by a transmission link between the core network and the UE comprising a UMTS wireless link. Streaming bearers can have transmission rates of different discrete values, e.g. 32 kbps or 64 kbps. A bearer can change its transmission rate, e.g. during a streaming session. Changing the transmission rate comprises switching from a first discrete rate value to a second discrete rate value. For a bearer changing its transmission rate, sometimes the term “elastic bearer” is used.
The streaming server contains a scheduler and a content storage comprising the content to be sent to the streaming client. The scheduler determines the sending rate at which the streaming data leaves the streaming server. The data in the content storage can be stored at different data formats and different data rates for matching the receiving capabilities of the streaming client and transmission capabilities of the transmission link interconnecting the streaming client and the streaming server. The data rates in the content storage and the sending rate can differ, however, for the reason of simplicity no differentiation is made between both rates in the following. Note that the streaming server does not necessarily have to be located outside the core network as indicated in FIG. 1. Instead, the streaming server can be located within the core network.
For starting the streaming of data, the streaming client requests (1), e.g. by using the Real-Time Streaming Protocol (RTSP), content from the streaming server, e.g. over an already existing connection which can be a best effort UMTS bearer. In response to this request (1), the streaming server provides (2) the streaming client with information at which rates the content can be streamed. The streaming client utilizes this information to request (3) at an entity of the core network of the mobile communication system a streaming bearer which is suited to operate on at least one of the available rates. The information on the rates at which the content can be streamed is transferred (4) to a radio resource management in a RNC that can make a reservation for appropriate radio resources depending on the received information such that the content can be streamed at one of the transmission rates supported by the streaming bearer. In a next step, a streaming bearer is established (5) between the core network and the user equipment for entering data into the streaming client. After the streaming bearer is established, the streaming server starts to send (6) the streaming content over the streaming bearer at one of the data rates matching to the receiving capabilities of the client.
The above example serves to illustrate a way for the sending entity to match its content and sending rate to the available receiver capability and for the interconnecting network to assign a transmission link that fits to the available receiving capability and to a sending rate which is a workable solution for the case that the interconnecting network can fulfill the requirements of meeting the sending rate. However, for the case that the interconnecting network chooses for any reasons a transmission link having a transmission capability not fitting to the sending rate of the sending entity or the transmission capability changes, applying existing mechanisms for obtaining information about the transmission capability of the transmission link as a base for a possible a matching decision have several shortcomings and drawbacks:
According to a first solution, it is possible to adapt an RNC serving an elastic bearer to signal the current bearer rate directly to a streaming server acting as sending entity. This kind of “network-feedback” solution, i.e. the signaling of the transmission rate of a transmission link from a network controller like an RNC or a BSC to a sending entity like the streaming server, requires changes in protocols on several standardized interfaces. Therefore, network-feedback solutions are generally regarded as very problematic to implement in a communication network being subject of standardization, e.g. mobile communication networks being compliant to the 3GPP standard.
According to a second solution, information about dropped data packets can be signaled via reports, e.g. according to the RTCP protocol, from the streaming client to the streaming server. Packet drops occur if the storage capacity, i.e. the buffer size, of the buffer before the bearer is exceeded. The reason is that the sending rate exceeds the bearer rate leading to an inflow of data packets into the buffer being higher than the outflow of data packets. If the buffer size is exceeded, packets are dropped at buffer overflow. About this stage, considering the time delay introduced by the transmission link and processing delays in the UE and the streaming client, the streaming client can detect the packet drops and can start to send RTCP reports comprising information about packet drops to the streaming server. Based on that, the streaming server is informed about Little buffer overflow and can deduct that the transmission rate is below the present sending rate. Further information about the transmission capability cannot be obtained by such packet drop solutions. However, packet drops should be generally avoided, e.g. because retransmissions of dropped packets may become necessary and the play out of streamed data at the streaming client may be interrupted. Packet drops are especially problematic for many real-time applications. Therefore, the solutions based on packet drops are generally regarded as too slow, because the sending entity can be informed earliest at a stage where packet losses already have occurred.
In summary, existing solutions for obtaining information about a transmission capability of a transmission link are difficult to implement, are slow, or provide insufficient information.